Shared state pattern (spin-off of #427) #430
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is spun out of #427 and focuses entirely on moving the API structs to a "shared state" pattern, reducing the prevalence of
Arc
in the API without any functional changes.This one is very subjective so I don't mind discarding it, but I felt that the prevalence of
Arc
in the API was adding noise that is seldom relevant to the average user. In this PR, I've refactored the API a little so thatNode
,Subscription
,Publisher
,Client
, andService
each have a respective_State
structure which is public and represents the underlying instance. At the same time,Node
,Subscription
, etc are now type aliases of the formpub type Node = Arc<NodeState>;
pub type Subscription<T> = Arc<SubscriptionState<T>>;
This does not lead to any actual change in the structure or memory management of any of these types; it's a purely superficial renaming. But it reduces how often
Arc
is tossed around in the API and thereby streamlines the 95% (my own estimate) of use cases whereArc
is just an implementation detail. At the same time, it does not interfere with the remaining 5% of use cases where theArc
is relevant, e.g. if a user wants to hold onto aWeak<Node>
for some reason.